In recent years it has been appreciated that the modification of control instructions in major systems is by no means a straightforward matter and over the years improved techniques have been developed for constructing large collections of instructions for operation in real time, in environments where errors could result in major systems failure.
A significant amount of time and money was often spent in the development of control instructions and, although it is often desirable to make upgrades, it is also desirable to obtain maximum benefit from existing code. Although the size of existing instruction is large and is often not consistent with modern development techniques, it does in itself provide two distinctive advantages. Firstly, it exists, and does not require additional investment in order for it to be created. Secondly, given the fact that generally, it will have been in operation for several years, it is tried and tested.
To an operational manager deriving benefits from existing systems, the associated instructions are perceived as something of great value, and is often referred to as "heritage" code. However, to the development engineer, the existing code provides major problems, in that it, generally, is not consistent with modern techniques and modern procedures. In particular, it has been found in recent years that object-oriented environments are particularly suited to defining telecommunications functionality, given their inherent modularity. Development Engineers tend not, therefore, to see existing earlier instruction suites in such glowing light and tend to refer to them as a "legacy" to be tolerated, rather than an inheritance to be appreciated!
When presented with a legacy system of this type it is not uncommon to be referring to several million lines of executable statements and maintenance engineers may adopt one of two clear strategies.
Firstly, they could continue to operate in the manner anticipated by their predecessors. Thus, they would continue to use the earlier techniques and develop systems in accordance with the tried and trusted methods. The second option would be to effectively discard all of the previous legacy instructions and start again, defining each of the modules in accordance with modern object-oriented techniques. However, although appearing to be attractive, such a strategy would in itself present several risks. Firstly, it is possible that the investment required would be too large, thereby creating an intolerable burden in terms of the development costs. Secondly, it is likely that the systems must interface with other systems, therefore it would not be entirely possible to disregard all of the legacy systems because they may belong to another party. Thirdly, a major re-write of all of the instructions would take a significant period of time. It is therefore possible that procedures adopted at the beginning of a development process, although modern in their time, would rapidly become out of date.
It is often possible to add modified and enhanced modules of instruction to existing large instruction sets. However, in order to do this it is necessary to accurately specify the way in which the new module must interface with existing modules. Furthermore, once a new module has been developed it is necessary to test it before it actually goes on-line. Testing is preferably performed automatically, at great speed, but it is necessary to develop suitable testing routines, sometimes referred to as test cases.
International Switching Symposium--Paper C10.2, vol. 2, October 1992, Yokohoma (JP), pages 439-443, XP000337756, Rouger et al: "Test cases generation from formal specifications" see page 441, paragraph 4 shows methods of generating test cases, and problems associated with such methods. In one approach, based on SDL, a global system behaviour of several modules is determined, paths are extracted from the system behaviour, and the paths are split between external interfaces. However, there is no disclosure of determining interface specifications of individual modules.
U.S. Pat. No. 4,617,613 shows a system for testing a communication system having a message based architecture. A message utility generates, manipulates, and verifies responses to, sequences of messages passed between a control system and the network being controlled. However, the message utility generates messages on the basis of scripts entered in a high level language by an operator, and thus there is considerable manual input, and no disclosure of determining interface specifications of modules.